WIP: continue migration to JUnit 5 (Plan B)#1321
Conversation
c7cab05 to
a72c921
Compare
|
Current state of this PR:
However, there is a runtime error. It seems like eclipse platform is conflicting with the maven platform junit. Caused by: java.lang.LinkageError: loader constraint violation: when resolving method 'org.junit.platform.launcher.core.LauncherDiscoveryRequestBuilder org.junit.platform.launcher.core.LauncherDiscoveryRequestBuilder.filters(org.junit.platform.engine.Filter[])' the class loader org.eclipse.tycho.surefire.osgibooter.SurefireLoader @428a51e of the current class, org/apache/maven/surefire/junitplatform/TestPlanScannerFilter, and the class loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @323846e1 for the method's defining class, org/junit/platform/launcher/core/LauncherDiscoveryRequestBuilder, have different Class objects for the type [Lorg/junit/platform/engine/Filter; used in the signature (org.apache.maven.surefire.junitplatform.TestPlanScannerFilter is in unnamed module of loader org.eclipse.tycho.surefire.osgibooter.SurefireLoader @428a51e, parent loader 'app'; org.junit.platform.launcher.core.LauncherDiscoveryRequestBuilder is in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @323846e1, parent loader 'platform') |
a54d40d to
4161246
Compare
4161246 to
c4503ec
Compare
Updated ddk.target file. Directed tycho to use JUnit5. Changed swtbot dependency to JUnit5. Removed JUnit4 dependencies. Removed custom JUnit4 runners.
c4503ec to
1d58413
Compare
Tests have been silently reporting "Tests run: 0" since dsldevkit#1292 (2026-04-01) bumped orbit-aggregation from 2025-09 to 4.39.0. Tycho-Surefire treats zero discovered tests as success, so CI remained green while test coverage dropped to nothing. Root cause: orbit-aggregation 4.38.0+ ships every JUnit Jupiter, Platform, and Vintage IU at both the 5.x and 6.x version families simultaneously. Tycho's planner pulls in both families, so the OSGi runtime ends up with two Class<?> instances of JUnit Platform types, producing LinkageError / ArrayStoreException during test discovery (different classloaders for the same FQN). orbit-aggregation 4.37.0 (Sept 2025) is the last release that ships JUnit at a single family (5.13.4 / Platform 1.13.4) and matches Eclipse 4.34's PDE JUnit runtime bridge. Pinning to it, removing the now-redundant maven-osgi/release/4.39.0 location, and inlining the JUnit IUs at 5.13.4 / 1.13.4 restores the three JUnit-Platform-bearing classloaders to a single agreed version. Also dropped: the unused releases/2022-12 UML2 location, which was a stealth source of additional JUnit 5.9.1 / 1.9.1 IUs (DDK does not consume any UML2 features). Verified locally on macOS aarch64: 307 tests across 75 classes, 0 failures. Tycho-Surefire's auto-detection selects the junit5vintage provider given Jupiter + vintage-engine on the classpath; no providerHint override is needed. This is step 1 of a staged plan. Subsequent PRs will: step 2 - migrate remaining JUnit 4 source surface to Jupiter step 3 - drop org.junit 4.13.2 and junit-vintage-engine entirely step 4 - upgrade to JUnit 6 + Eclipse 4.39 atomically Credit: Kris Limbo's dsldevkit#1320 / dsldevkit#1321 (Plan A / Plan B) proved the JUnit 5 migration direction; both encountered the same LinkageError during diagnosis that this fix sidesteps via version alignment. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Tests have been silently reporting "Tests run: 0" since #1292 (2026-04-01) bumped orbit-aggregation from 2025-09 to 4.39.0. Tycho-Surefire treats zero discovered tests as success, so CI remained green while test coverage dropped to nothing. Root cause: orbit-aggregation 4.38.0+ ships every JUnit Jupiter, Platform, and Vintage IU at both the 5.x and 6.x version families simultaneously. Tycho's planner pulls in both families, so the OSGi runtime ends up with two Class<?> instances of JUnit Platform types, producing LinkageError / ArrayStoreException during test discovery (different classloaders for the same FQN). orbit-aggregation 4.37.0 (Sept 2025) is the last release that ships JUnit at a single family (5.13.4 / Platform 1.13.4) and matches Eclipse 4.34's PDE JUnit runtime bridge. Pinning to it, removing the now-redundant maven-osgi/release/4.39.0 location, and inlining the JUnit IUs at 5.13.4 / 1.13.4 restores the three JUnit-Platform-bearing classloaders to a single agreed version. Also dropped: the unused releases/2022-12 UML2 location, which was a stealth source of additional JUnit 5.9.1 / 1.9.1 IUs (DDK does not consume any UML2 features). Verified locally on macOS aarch64: 307 tests across 75 classes, 0 failures. Tycho-Surefire's auto-detection selects the junit5vintage provider given Jupiter + vintage-engine on the classpath; no providerHint override is needed. This is step 1 of a staged plan. Subsequent PRs will: step 2 - migrate remaining JUnit 4 source surface to Jupiter step 3 - drop org.junit 4.13.2 and junit-vintage-engine entirely step 4 - upgrade to JUnit 6 + Eclipse 4.39 atomically Credit: Kris Limbo's #1320 / #1321 (Plan A / Plan B) proved the JUnit 5 migration direction; both encountered the same LinkageError during diagnosis that this fix sidesteps via version alignment. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
A different approach from ACF-13681-A. This approach results in a runtime error,
.
#1324 and related PRs document the way forward to fix the JUnit tests for the DDK.
According to PR#1324, the problem with this PR and PR#1321 is as follows:
Root cause: orbit-aggregation 4.38.0+ ships every JUnit Jupiter, Platform, and Vintage IU at both the 5.x and 6.x version families simultaneously. Tycho's planner pulls in both families, so the OSGi runtime ends up with two Class<?> instances of JUnit Platform types, producing LinkageError / ArrayStoreException during test discovery (different classloaders for the same FQN).
orbit-aggregation 4.37.0 (Sept 2025) is the last release that ships JUnit at a single family (5.13.4 / Platform 1.13.4) and
matches Eclipse 4.34's PDE JUnit runtime bridge.